Improve Log4j Core configuration file detection for Log4j 3 #46409
+161
−59
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
spring-projects-issues
added
the
status: waiting-for-triage
Log4j Core 3 has undergone significant modularization and no longer uses optional parser dependencies. This change requires updates to Spring Boot's configuration file detection logic to properly support both Log4j Core 2 and 3. * **Updated configuration file detection** Spring Boot now detects configuration formats based on the presence of `ConfigurationFactory` implementations, instead of relying on optional parser dependencies (as was the case in Log4j Core 2). * **Improved classloader usage for reflection** Reflection logic now uses the classloader that loaded Log4j Core, rather than the one associated with the Spring Boot context, ensuring greater compatibility in modular environments. * **Adjusted configuration file lookup order** The lookup now prioritizes configuration files specified via properties over automatically discovered ones, improving consistency with Log4j Core. * **Support for contextual configuration files** Files named in the form `log4j2<contextName>.<extension>` are now also supported. These changes ensure compatibility with Log4j Core 3 while preserving support for Log4j Core 2, improving Spring Boot's flexibility in detecting and loading user-defined logging configurations. > [!NOTE] > The configuration file detection logic introduced here could potentially be moved into a future version of Log4j Core itself. For more context, see apache/logging-log4j2#3775. Signed-off-by: Piotr P. Karwasz <piotr@github.copernik.eu>
ppkarwasz
force-pushed
the
feat/log4j-core-3-configuration
branch
from
0de4595 to
2c40cad
Compare
Signed-off-by: Piotr P. Karwasz <piotr@github.copernik.eu>
core/spring-boot/src/main/java/org/springframework/boot/logging/log4j2/Log4J2LoggingSystem.java
Show resolved
Hide resolved
mhalbritter
changed the title
mhalbritter
added
type: enhancement
mhalbritter
pushed a commit
that referenced
this pull request
Aug 29, 2025
Log4j Core 3 has undergone significant modularization and no longer uses optional parser dependencies. This change requires updates to Spring Boot's configuration file detection logic to properly support both Log4j Core 2 and 3. **Updated configuration file detection** Spring Boot now detects configuration formats based on the presence of ConfigurationFactory implementations, instead of relying on optional parser dependencies (as was the case in Log4j Core 2). **Improved classloader usage for reflection** Reflection logic now uses the classloader that loaded Log4j Core, rather than the one associated with the Spring Boot context, ensuring greater compatibility in modular environments. * **Adjusted configuration file lookup order** The lookup now prioritizes configuration files specified via properties over automatically discovered ones, improving consistency with Log4j Core. **Support for contextual configuration files** Files named in the form `log4j2<contextName>.<extension>` are now also supported. These changes ensure compatibility with Log4j Core 3 while preserving support for Log4j Core 2, improving Spring Boot's flexibility in detecting and loading user-defined logging configurations. See gh-46409 Signed-off-by: Piotr P. Karwasz <piotr@github.copernik.eu>
mhalbritter
added a commit
that referenced
this pull request
Aug 29, 2025
|
Thanks @ppkarwasz ! |
|
@mhalbritter thanks a lot for merging this! 💯 For context: this PR was our contingency plan to ensure Spring Boot 4 is fully compatible with Log4j Core 3. From the SB integration’s perspective, the only real breaking change in 3.x is the modularization of configuration factories. In the short term (starting with public Configuration getConfiguration(LoggerContext, String, List<URI>);as discussed in apache/logging-log4j2#3839. We believe this is the key missing piece that currently forces you to depend on so many Log4j Core internals ( Since our project is entirely volunteer-driven, we can’t promise to hit the |
|
My pleasure. Please let us know when the new API lands and we can see how and in which version we can use it. Thanks! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Log4j Core 3 has undergone significant modularization and no longer uses optional parser dependencies. This change requires updates to Spring Boot's configuration file detection logic to properly support both Log4j Core 2 and 3.
Summary of Changes
Updated configuration file detection
Spring Boot now detects configuration formats also based on the presence of
ConfigurationFactoryimplementations, instead of only relying on optional parser dependencies (as was the case in Log4j Core 2).Improved classloader usage for reflection
Reflection logic now uses the classloader that loaded Log4j Core, rather than the one associated with the Spring Boot context, ensuring greater compatibility in modular environments.
Adjusted configuration file lookup order
The lookup now prioritizes configuration files specified via properties over automatically discovered ones, improving consistency with Log4j Core.
Support for contextual configuration files
Files named in the form
log4j2<contextName>.<extension>are now also supported.These changes ensure compatibility with Log4j Core 3 while preserving support for Log4j Core 2, improving Spring Boot's flexibility in detecting and loading user-defined logging configurations.
Note
The configuration file detection logic introduced here could potentially be moved into a future version of Log4j Core itself. For more context, see apache/logging-log4j2#3775.